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DEVELOPMENTS 

THE NliWSLE'ITIiR FROM PACKET FORENSICS COVERING INDUSTRY AND PRODUCT EVOLUTION 

VbuVe got a Man in the Middle 

An automated Approach to InterceptingTraffic in encryptedTunnels 



Internet communications are increasingly l>eing 
protected by transport layer security (“TLS”) or the 
secure socket layer (“SSLO. These are simple ad-hoc 
virtual private networks protected by encryption. 
'I'hcy operate at the transport layer, usually over 
TCP. Once used exclusively by web servers to 
protect transactions, these technologies are now 
also used to protect e-mail access, voice over IP 
telephony and even entire Internet connections. 

'Phis pervasive adoption has created major 
problems for lawful interception and technical 
investigations because intercepting this traffic has 
traditionally resulted in capturing nothing but 
unreadable fodder. 




There have been a slew of “attempted solutions” 
in the recent past that made intercepting some of 
this traffic possible, but all previous attempts failed 
in the areas of reliability and complexity of setup— 
this often resulted in the accidental disruption of 
subscribers’ communications all together, an 
unacceptable risk for most of us. As if that wasn’t 
bad enough, most attempted solutions involved 
specific application-layer protocols and were tied to 
those protocols. 'Phis meant they worked with web, 
but not with VoIP and so on... All things considered, 
the juice wasn’t worth the squeeze^. 



After much / \ 

effort, we’re excited 
to offer a solution (I 
that doesn’t suffer 

from these previous limitations. Our solution docs 
just what you’d expect: you can see inside encrypted 
tunnels and capture whatever traffic is being 
protected— web, e-mail, voice over IP, et al, 
regardless of the port numbers or protocol being 
tunneled. It works with all our existing targeting and 
policy features and there’s even a wizard to 
configure it through our graphical management 
software. 

WAYS AND MEANS 

Contrary to what many believe, interception of 
communications protected with high-assurance 
cryptography isn’t always about defeating or 
cracking the encryption— it’s usually about getting 
the encryption keys yourself so you can decrypt at- 
will and therefore the encryption doesn’t matter. 
This applies generally to both standalone encrypted 
materials and communications encryption. 

On the topic of TLS and SSL, this is 
accomplished by way of a “ man-in-thc-middlc " or 
“bucket brigade” attack. In its simplest form, a 
device *£’ is placed somewhere in between the 
communications network connecting ’A' to ‘B’ and 
it Ijecomes an unintended go-between, speaking to 
A and B independently while relaying information 
between them— of course that information is first 
subject to its purview. When an encrypted tunnel is 
negotiated, instead of creating a tunnel between A 
and B, two tunnels actually get created— one from A 
to E and another from E to B. When done 
correctly, A and B are made to believe they are 
directly connected over an encrypted tunnel and the 
information transmitted between them is 
cryptographically secure. All the while, E sees all. 
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Technical Details 

Man-ln-the-Middle Capabilities 

Intercept any communication within 
Secure Socket Layer (SSL) or Transport 
Layer Security (TLS) sessions 

All Packet Forensics targeting and policy 
capabilities can operate within the 
encrypted tunnel 

Operational Configurations 

In-line with hardware bypass / failsafe 

Import any certificate / public key or 
generate your own for presentation 

Availability 

Available in firmware releases after 
August 3 1 St, 2009 for all Packet 
Forensics platforms 

Available under customization program 



Contacts 

Offices in 
Virginia and 
Arizona, USA 



Headquarters 

420 S Smith Rd 
Tempe,AZ 85281 
United States of America 

Telephone & E-mail 

Domestic US +1 (800) 807 6140 
International + 1 (757) 320 2002 
salesteam@packetforensics.com 
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now DOIuS IT WORK.> 

Deployment and Capabilities 

Just as it sounds, engaging in a 
man-in-the-middle attack requires 
the interception device to be 
placed in-line between the parties 
to be intercepted at some point in 
the network. 'ITiis could be at the 
subscribers’ telecom operator or 
even on-premises, close to the 
subject. Packet Forensics’ devices 
are designed to be inserted-into 
and removed-from busy networks 
without causing any noticeable 
interruption. Even the failure of a 
device due to power loss or other 
factors is mitigated by our 
hardware bypass fail-safe system. 
Once in place, devices have the 
capability to l>ecomc a go-between 
for any TLS or SSL connections in 
addition to having access to all 
unprotected traffic. This allows 
you to conditionally intercept 
web, e-mail, VoIP and other traffic 
at-will, even while it remains 
protected inside an encrypted 
tunnel on the wire. All the same 
capabilities as other Packet 
Forensics products are still 
available, including the ability to 
extract pen/trap details only. 

Technical Considerations: PKi 

Using “man-in-the-middlc” to 
intercept TI^ or SSL is essentially 
an attack against the underlying 
Diffie-Hellman cryptographic key 
agreement protocol. 'lb protect 
against such attacks, public key 
infrastructure (“PKI’O is often 
used to authenticate one or more 
sides of the tunnel by exchanging 
certain keys in advance, usually 
out-of4)and. 'Fhis is meant to 
provide assurance that no one is 
acting as an intermediary. Secure 
web access (I I'TTP-S) is the l>est 
example of this, because when an 



unexpected key is encountered, a 
web browser can warn the subject 
and give them an opportunity to 
accepL the key or decline^ the 
connection. 




To use our product in this 
scenario, users have the ability to 
import a copy of any legitimate 
key they obtain (potentially by 
court order) or they can generate 
“look-alike” keys designed to give 
the subject a false sense of 
confidence in its authenticity. 

Of course, this is only a 
concern for communications 
incorporating PKI. For most 
other protocols riding inside TLS 
or SSL tunncls“where no PKI is 
employed— interception happens 
seamlessly without any subscriber 
knowledge or involvement. 

I low CAN YOU USE FI? 

Government Security 

IP communications adoption 
dictates the need to examine 
encrypted traffic at-will, especially 
transiting government networks. 

Investigations 

Your investigative staff will 
likely collect its best evidence 
while users are lulled into a false 
sense of security afforded by web, 
e-mail or VoIP encryption. 

Product Testing and Evaluation 

All network pnxlucts should 
be tested diligently for phone- 
home capabilities with encryption. 
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DEVELOPMENTS 

THE NEWSUriTHR FROM PACKET FORENSICS COVERING INDUSTRY AND PRODUCT EVOLUTION 

Private VoIP Exchanges & the lAX Dilemma 

Explosive Growth of I AX Protocol and International VoIP Trunking leaves Industry Unprepared 



In June of 2009, Packet Forensics undertook a 
comprehensive research effort with the help of one 
of our partners, a global telecommunications service 
provider. Their network represents a large cross- 
section of the greater North American IP backbone 
because they are a tier-i Internet service provider, or 
to what people commonly refer as a carrier’s carrier. 
Amongst a larger agenda, we sought to unearth 
quantitative details related to actual VoIP protocol 
usage— what are people using to transport VoIP 
traffic and are they trunking to several large carriers 
or is there a preponderance of peerto-peer traffic or 
interconnectivity between PBXs and providers. 
What we found not only surprised us, but warranted 
immediate action on our part to fill gaps in our 
product portfolio and to inform our current 
customers who rely upon us for passive VoIP 
monitoring and interception. 

In order to preserve subscriber privacy, deep 
packet inspection (DPI) was used only to positively 
identify protocols and because of privacy sensitivity, 
we did not determine if calls were being executed 
independently or trunked. Traffic flow records were 
analyzed to identify statistically significant networks 
of call origination and termination and to get a 
sense of which protocols were l>eing used in which 
telephony situations. 

The high level results of the analysis provided 
unexpected answers and insight. First, MGCP is still 
used across the public Internet, not only within 
enterprises. Second, H.323 remains the heavy-lifter 
for teleconferencing. Finally, IntcrAsterisk 
Exchange (lAX) protocol now comprises a double- 
digit percentage of VoIP. This is particularly 
interesting when you consider lAX traffic 
occupies only one stream for potentially 
dozens of calls when trunking. Consider 
also that although lAX is an open 
standard, the vast majority of telephony 
jglatform^mglement^^ 




North American Backiwnc VoIP Protocol Distril>ution»Junc 2009 

commercial, public domain applications that don’t 
include facilities for active interception capability. 
This means I A X tn^dic must be captured passively and 
doing so retjuires systems like ours. The speed of 
lAX adoption is nothing short of amazing. lAX is 
very different from most VoIP protocols, but its 
unique characteristics likely drove its adoption. 

First, it’s a binary protocol as opposed to text-based. 
Second, it doesn’t use R'FP to carry call content. 
Instead, it offers a novel approach that aggregates 
both content and signaling into one stream making 
it NAT-friendly and vastly more efficient than RTP 
with two thirds less overhead per packet. 

Suffice it to say, much of our engineering time 
late last year was spent in support of 
MGCP and lAX development and we’re 
proud to say that we’re now the first and 
inly passive capture solution for lAX. We 
even support lAX’s optional trunking 
configurations. It’s been a busy quarter around 
here, and a productive one for our customers. 
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O FHER OBSERVATIONS 

Enterprises Using Internet VoIP 

Thousands of enterprises are 
using their Internet connections 
to transmit VoIP to other 
enterprises and to third-party 
termination providers. Instead of 
using their Internet provider’s 
telephony products exclusively, 
they utilize specialized VoIP 
service providers for termination 
and potentially origination. 'ITiese 
service providers may l>e located 
in other countries and generally 
support SI P and/or I AX protocols. 
Very few (less than one percent) of 
the providers we tested support 
encryption of signaling or content. 

Termination and Origination 

Some origination and 
termination accounts can be 
purchased in retail locations for 
cash without requiring verifiable 
identification for activation. Most 
service providers can provision 
telephone numbers in hundreds of 
locales within seconds through on- 
line web management interfaces. 
Most honor client-supplietl caller- 
id information which means their 
customers can make calls appear 
to originate from any telephone 
number. Calling-name (CNAM) 
service makes this particularly 
convincing by adding the name 
portion to the caller-id based upon 
telephone number lookup only. 



Calling Card Operators 

Many international streams 
occur between non-fadlities-bascd 
VoIP wholesalers who appear to 
operate calling card services. 

Ni: W lAX CAPABILITIES 

Monitoring and Interception 

Packet Forensics devices now 
hilly-support the lAX protocol 
including its trunking capabilities. 
Targeting lAX calls for 
interception works the same as 
our SIP implementation where 
users can specify telephone 
numbers and call direction as well 
as IP addresses, UR Is and any of 
our other advanced policy criteria. 

Data Availability and Formats 

Users can capture signaling, 
content or Ixith to satisfy their 
needs as well as extract dialed 
digits and other meta-data. 

Other Capabiiities 

Our pen-style reporting has 
been updated to provide textual 
details about lAX sessions. 

'I'he Packet Forensics direct 
audio (RTP) player application has 
been enhanced to include lAX 
audio mixing, selection and 
playback, making it even more 
flexible and useful for VoIP 
troubleshooting and monitoring. 




Technical Details 

lAX VoIP Support 

lAX / IAX2 (RFC 5456) 

In-band audio and dialed digits 
In-band mink meta packets 
Direct audio playback support 

AJI Packet Forensics targeting and policy 
capabilities can be used to target calls 
and perform other tasks 

Operational Configurations 

In-line with hardware bypass / failsafe 
Tap / Mirror / SPAN 

Availability 

Available in firmware releases after 
January 2010 for all platforms 

Available under customization program 



Contacts 

Offices in 
Virginia and 
Arizona, USA 



Headquarters 

420 S Smith Rd 
Tempe.AZ 85281 
United States of America 

Telephone & E-mail 

Domestic US + 1 (800) 807 6 1 40 
International + 1 (757) 320 2002 
salesteam@packetforensics.com 
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